Replication block

The replication block specifies conditions for replicating variables and prior to Unreal Engine 3 also for functions. It contains one or more replication conditions, each with one or more variable or function names to which the condition applies.

Syntax

The general syntax of the replication block looks as follows:

replication
{
  condition 1
  condition 2
  ...
}

Replication conditions in Unreal Engine 1 and 2 have the following syntax:

[un]reliable if (boolean expression)
  variable or function name [, ...] ;

The keyword reliable or unreliable only affects functions, but still must be specified for variables even though it doesn't make a difference there. Unreliably replicated function calls may be dropped due to bandwidth saturation, while reliably replicated function calls will be delayed in that case.

Unreal Engine 3 uses simplified replication conditions because function replication is specified via function modifiers:

if (boolean expression)
  variable name [, ...] ;

Typically a replication condition tests the local value of the Role property, usually as Role == ROLE_Authority for server-to-client replication or Role != ROLE_Authority for client-to-server replication. For replicated functions this is usually the only condition.

In Unreal Engine 1 variables can be replicated from the server to all clients, but also from the client owning the actor to the server, similar to replicated function calls. That's why Unreal engine 1 replication conditions always check the Role. In Unreal Engine 2 and 3 variables can only be replicated from the server to clients, so technically the Role doesn't need to be checked at all. Still even Epic code contains Role checks for replicated variables in many classes.

For variable replication there are also other useful actor properties, such as bNetInitial and bNetOwner, which further narrow down when to replicate the variable and who to replicate it to.

Unlike any other data type in UnrealScript, dynamic arrays have absolutely no support for replication whatsoever. Attempting to replicate a dynamic array variable will have no effect on the remote instance of that variable. Attempting to use a dynamic array as parameter of a replicated function will result in the parameter being empty when the function is executed on the remote side. Similar restrictions apply to dynamic arrays within replicated struct values.

Exceptions

For relatively obvious reasons, functions declared as static, latent or iterator can't or shouldn't be replicated. Functions replicated to clients must be declared as simulated if you want them to be executable on ROLE_SimulatedProxy or ROLE_DumbProxy clients. Note that the UE3 function modifiers client or demorecording already imply the simulated modifier, so you don't need to specify it again. The same goes for the native function modifier. Whether the similar DLLImport modifier implies simulated (or whether such functions support replication at all) is currently unknown, but then again you probably don't want to call such a function directly via replication.

If a class is declared with the NativeReplication modifiers, the replication conditions in its replication block are ignored for variables. Instead variable replication conditions are defined in native code. Function replication conditions are still specified in the replication block (or in UE3 via function modifiers) as usual. The reason these classes still contain replication conditions for variables is that UnrealScript coders should know when variables are actually replicated. The information may be inaccurate though, as the UT2004 Pickup class shows. Its bOnlyReplicateHidden property turns off replication for all but the bHidden property.

Replicating variables declared as config, globalconfig or localized may not have the desired effect as these variables may have different initial values on the server and the clients. The configured or localized values are the default values on the server and replication only kicks in if the values have changed.